違うルートの地図ぐらいみてもいいんじゃない
世間には様々な設計手法やメソッドや知識体系があります。BOK系はPMBOK、SWEBOK、SQuBOK、BABOK、SABOK、REBOK、DMBOK…。アジャイルに関連するものなら、スクラム、エクストリーム・プログラミング。最近はリーンやかんばんに注目が集まっています。UXデザインはこれといったプロセスはまだ定義されていないように思いますが、関連するプラクティスは数多くあります。近いところではラショナル統一プロセス。ウォーターフォールだって立派な開発プロセスで論文だって書かれています(その論文のウォーターフォールと私たちがよく目にするウォーターフォールはだいぶ違うものですが)。◯◯駆動開発、◯◯駆動設計はどうでしょう。最近なにかと話題になるドメイン駆動設計、そしてユースケース駆動開発。先ほどBABOKを上げたが日本には近しい領域に要求開発(Openthology)があります。設計・実装に踏み込んでいけば、遡れば構造化分析設計があり、その後、オブジェクト指向があらわれ、それからアスペクト指向などもあります。
……本当にいっぱいあります。キリがないですね。これらについて私が思っていることを書こうかと。
- 思っていること1:どれも銀の弾丸にはならない
システム開発プロジェクトにおいてプロジェクトマネジメント技術の拙さが炎上や失敗をまねくといわれ、PMBOKによって解決するかと思われましたがそんなことはありませんでした。もちろん、それまでよりは上手にプロジェクトをマネジメントすることができるようになったのかもしれませんが、PMBOKはプロジェクトマネジメント専門の知識体系であり、経営やビジネスアナリシスについてはほとんど言及していません。ソフトウェアエンジニアリングについても書いていません。それぞれの専門的な領域について書いているので、それを補うための知識は必要になるし、そもそもプロジェクトというものはいつも同じパターンですんなりいくようなものではないのです。
- 思っていること2:(おっきな)目的はいっしょ
実は扱っている領域こそ違いますが、そこに書かれていることは「もっとうまくやろう」とする心ではないでしょうか。私たちの仕事で言えば「より良いソフトウェアをつくろう」という事になります。大きな目標ですが、それはどのメソッドも一緒です。つまり同じ山の頂上を目指しているが、採択するルートが違うだけで、それに気がつけばあらゆるメソッドの本質的に共通する何かがあるのは当然で不思議なことでもなんでもないと思います。
- 思っていること3:ひとつ知る
こういったメソッド系のものを何から何まで目を通し把握する必要はありません。それは時間がもったいない。しかし自分の専門領域に関わりのあるものを一つくらいは目を通してみることをオススメします。すでに知っていたことがかかれているかもしれませんが、それらを体系的に整理してくれるのに役立ちます。使う言葉が揃うので近い領域の専門家ともコミュニケーションがしやすくなります。
- 思っていること4:他も知る
そして余裕ができたら、他のメソッドにも目を通してみてください。もしかしたら既に読んだものと共通することが書いてあるかもしれませんが、それは共通して大事なことなのだと理解すれば良いのです。違うことが書いてあったとしたら。それはそれでいいでしょう。なぜなら「より良いソフトウェアを作る」という目的は一致しているのだから、その違うことも学べば良いのです。いつかその違う方面からのアプローチが必要になる時があるのかもしれません。それは違う方面の人たちと一緒に仕事をすれば確実にそういうことになるはずです。そして、その違いと共通点を知ったあなたは、そのことを他の人に教えてあげればよいのです。
- まとめ
ITシステムやソフトウェアの開発に関わる人なら誰でも知っていることですが、単一技術、単一言語だけでは作りきれることはほとんどないでしょう。人の役に立つ良いソフトウェアを作るためには、いくつかの言語や技術を組み合わせてつくっていくことになります。これはメソッドについても同様で、単一のメソッドだけで上手くいくことは非常に少ないものです。例を上げると、設計の話になりますがUMLは設計において優れた言語ですが、今日のソフトウェア開発においてユーザーの感情を無視することはできず、その点に置いてUMLは表現の術をもたないので不完全なものです。しかしそれはユーザビリティ、UXデザインの概念や手法を取り入れることで補うことができます。このように組み合わせることで、より良いソフトウェア開発に近づくのではないでしょうか。ちなみにこういった複数手法の組み合わせについてはこれといったメソッドすら存在しないので、実践を通じて経験を積み重ねていくしかありません。この「あらゆるルートから頂上を目指すことができる能力」と「その経験の蓄積」は組織やチームの数値化はできないが貴重な資産であると思います。